Skip to content

Conversation

@ikusakov2
Copy link

@ikusakov2 ikusakov2 commented Jan 7, 2026

Description

This PR includes the fix to the following issue: enums from external fragment were not copied to the generated file along with operations.

Additionally, an integrated test is added:
dev-test-apollo-tooling
That mimics the Apollo-tooling setup.

Testing

  • Unit tests

@ikusakov2 ikusakov2 changed the title An intergration test showing errors with recent alpha version An integration test showing errors with recent alpha version Jan 7, 2026
@ikusakov2 ikusakov2 changed the base branch from master to master-next January 7, 2026 20:27
@changeset-bot
Copy link

changeset-bot bot commented Jan 7, 2026

🦋 Changeset detected

Latest commit: 3839b02

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@graphql-codegen/typescript-operations Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@ikusakov2 ikusakov2 marked this pull request as ready for review January 7, 2026 22:03
Comment on lines 125 to 128
const documentWithExternalFragments: DocumentNode = {
...documentNode,
definitions: [...documentNode.definitions, ...(config.externalFragments || []).map(f => f.node)],
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the functionality in the above statement used to create allFragments could be used for our fragments here somehow? 🤔
It seems to do a similar function of collecting fragments, either from documents or from config.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call!
Check the new code - I combined it with allFragments.

@@ -0,0 +1,2 @@
**/__generated__/**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel we should unignore the generation 🙂
This could be a good test that can be kept as snapshot test, and an advanced use case of codegen

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, generated files added!

@@ -0,0 +1,106 @@
#!/usr/bin/env ts-node
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created the dev-test-alpha just as a temporary package to demonstrate our company issues.
Do you think it would be worth keeping it?
Then:

  • I'll need to add some tests which would get invoked when global tests are running.
  • We need to come up with some better name than dev-test-alpha

Copy link
Collaborator

@eddeee888 eddeee888 Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think so! I find this test is very valuable, as it can be used to catch unexpected bugs, at least in the initial stage after rolling out.

I feel we might be able to simplify a few things in the setup. And worst case, if its usefulness is overshadowed by maintenance, we can decide to drop it (or further simplify) later 🙂

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I renamed dev-test-alpha to dev-test-apollo-tooling - to give a more descriptive name to what this integration test it about. I also added another (hopefully last) fix - so you can run yarn install && yarn build from the root directory: graphql-code-generator and - it should work.

// @generated
// This file was automatically generated and should not be edited.

import type * as Types from '../../graphql-code-generator/dev-test-alpha/src/__generated__/globalTypes';
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we already worked on removing this line in typescript-operations plugin.
But it probably comes from near-operation-file preset.
Shall we ignore it until we do the next version of near-operation-file?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a research and - yes, it comes from near-operation-file.


type Exact<T extends { [key: string]: unknown }> = { [K in keyof T]: T[K] };
export type Incremental<T> = T | { [P in keyof T]?: P extends ' $fragmentName' | '__typename' ? T[P] : never };
export enum UserManagerRoleType {
Copy link
Author

@ikusakov2 ikusakov2 Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the recent fix - it adds the enum in the correct file.

@ikusakov2 ikusakov2 closed this Jan 8, 2026
@ikusakov2 ikusakov2 deleted the feature/add-config-extractAllFieldsToTypesCompact branch January 8, 2026 23:00
@ikusakov2 ikusakov2 restored the feature/add-config-extractAllFieldsToTypesCompact branch January 8, 2026 23:02
@ikusakov2 ikusakov2 reopened this Jan 8, 2026
@ikusakov2 ikusakov2 changed the title An integration test showing errors with recent alpha version Fixing an issue with including enums from external fragments Jan 12, 2026
@ikusakov2 ikusakov2 changed the title Fixing an issue with including enums from external fragments Bugfix: enums from external fragments were not generated along with operations Jan 12, 2026
* @see https://github.com/apollographql/apollo-tooling/issues/2053
* */
const GRAPHQL_CODEGEN_CONFIG = {
skipTypename: false,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This config doesn't exist anymore 🙂

const GRAPHQL_CODEGEN_CONFIG = {
skipTypename: false,
useTypeImports: true,
preResolveTypes: true, // Simplifies the generated types
Copy link
Collaborator

@eddeee888 eddeee888 Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

preResolveTypes: true is the only option now, and it's been removed entirely.
So we can omit it (when we are ready to merge)


import type * as Types from '../unused';

type Exact<T extends { [key: string]: unknown }> = { [K in keyof T]: T[K] };
Copy link
Collaborator

@eddeee888 eddeee888 Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Context/braindump, not a comment on this PR)

I made a TODO about Exact being generated but not used in files with only fragments in the feature PR. Some users' tsconfig.json may have strict types so it'd fail tsc.

I believe we are generating Exact all the time, but we should only do it if operations have been found in a document. I can take a look into that in a different PR.

"typescript": "5.5.4",
"eslint-plugin-promise": "7.1.0"
"eslint-plugin-promise": "7.1.0",
"graphql": "16.9.0"
Copy link
Collaborator

@eddeee888 eddeee888 Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think resolving a particular version of graphql is usually done in CI, when we test multiple versions of GraphQL in different actions.

Do we need this for this PR? 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants